Ben Chehade's Kommentar: In diesem Abschnitt beginnen wir mit der Informationsbeschaffung über das Zielsystem. Dies ist ein entscheidender Schritt, um ein tiefes Verständnis für die potenziellen Angriffsflächen zu entwickeln. Wir werden verschiedene Tools und Techniken einsetzen, um Informationen über das Netzwerk, die laufenden Dienste und die verwendeten Technologien zu sammeln.
Ben Chehade's Kommentar:
Hier verwenden wir arp-scan -l, um alle aktiven Hosts in unserem lokalen Netzwerk zu scannen.
Das Ergebnis zeigt, dass die IP-Adresse 192.168.2.141 dem Host mit der MAC-Adresse 08:00:27:16:1d:5f zugeordnet ist, was auf eine Maschine von PCS Systemtechnik GmbH hindeutet.
Diese Information ist nützlich, um das Zielsystem im Netzwerk zu identifizieren.
Ben Chehade's Kommentar:
Wir fügen die IP-Adresse und den Hostnamen "bulldog.vuln" zur Datei /etc/hosts hinzu, um die Namensauflösung für das Zielsystem zu erleichtern.
Dadurch können wir den Hostnamen anstelle der IP-Adresse verwenden, was die Arbeit im weiteren Verlauf des Pentests vereinfacht.
Ben Chehade's Kommentar:
Hier führen wir einen umfassenden Nmap-Scan durch, um offene Ports, laufende Dienste und das Betriebssystem des Zielsystems zu identifizieren.
Die Optionen bedeuten:
-sS: TCP-SYN-Scan (Stealth-Scan)
-sC: Führt Standard-Skripte zur Erkennung von Diensten aus
-Pn: Verhindert Host-Discovery-Pings
-AO: Aggressiver Modus, der OS-Erkennung und Traceroute kombiniert
-p-: Scannt alle 65535 Ports
Die Ergebnisse zeigen, dass SSH (Port 23) und HTTP (Port 80) offen sind. Interessanterweise ist Port 8080 gefiltert, was auf einen HTTP-Proxy hindeutet.
Nmap identifiziert das Betriebssystem als Linux 3.2 - 4.9.
Ben Chehade's Kommentar: Nachdem wir die offenen Ports und Dienste identifiziert haben, konzentrieren wir uns nun auf die Webanwendungen, die auf Port 80 laufen. Wir werden Tools wie Gobuster verwenden, um versteckte Verzeichnisse und Dateien zu finden, die weitere Einblicke in die Architektur und potenziellen Schwachstellen der Anwendung geben könnten.
Ben Chehade's Kommentar:
Wir verwenden Gobuster, um das Zielsystem auf versteckte Verzeichnisse und Dateien zu überprüfen.
Die Optionen bedeuten:
-u: URL des Zielsystems
-x: Dateiendungen, nach denen gesucht werden soll
-w: Wordlist mit Dateinamen und Verzeichnissen
-b: Ignoriert die Statuscodes 403 und 404
-e: Gibt die vollständige URL in der Ausgabe an
--no-error: Unterdrückt Fehlermeldungen
Die Ergebnisse zeigen, dass die Verzeichnisse "/admin", "/dev", "/notice" und die Datei "robots.txt" gefunden wurden.
Diese Informationen sind nützlich, um die Architektur der Webanwendung zu verstehen und potenzielle Angriffsflächen zu identifizieren.
Ben Chehade's Kommentar: Beim Aufrufen der Datei "robots.txt" im Browser wird eine ASCII-Art-Nachricht angezeigt, die auf humorvolle Weise auf die Kompromittierung des Systems hinweist. Dies ist ein Hinweis darauf, dass die Entwickler möglicherweise eine spielerische Herangehensweise an die Sicherheit des Systems haben.
Ben Chehade's Kommentar: Die Seite "/notice/" enthält eine Nachricht des CEO von Bulldog Industries, die einen Einblick in die Denkweise des Unternehmens gibt. Die Nachricht deutet auf eine frühere Sicherheitsverletzung hin und zeigt eine humorvolle und leichtfertige Haltung gegenüber Sicherheitsfragen. Dies könnte auf potenzielle Schwachstellen im Sicherheitsbewusstsein und in den Praktiken des Unternehmens hindeuten.
Ben Chehade's Kommentar: Das Verzeichnis "/dev/" enthält eine Liste von E-Mail-Adressen verschiedener Teammitglieder. Dies ist eine wertvolle Informationsquelle, da diese E-Mail-Adressen später für Social-Engineering-Angriffe oder zur Identifizierung von Benutzernamen verwendet werden können.
Ben Chehade's Kommentar: Unter "/dev/shell/" finden wir eine Web-Shell, die eine Authentifizierung erfordert. Die Liste der E-Mail-Adressen deutet darauf hin, dass diese als Benutzernamen verwendet werden könnten. Dies ist ein vielversprechender Angriffspunkt, da wir nun versuchen können, die zugehörigen Passwörter zu finden oder zu erraten.
Ben Chehade's Kommentar: Wir extrahieren die Benutzernamen aus den E-Mail-Adressen, um eine Liste potenzieller Benutzernamen für Brute-Force-Angriffe oder Passwort-Cracking zu erstellen.
Ben Chehade's Kommentar: Wir laden das Bild "bulldog.jpg" von Port 8080 herunter. Dies könnte uns weitere Informationen über das System liefern, z. B. Metadaten oder versteckte Informationen im Bild selbst.
Ben Chehade's Kommentar: Wir verwenden Exiftool, um die Metadaten des Bildes "bulldog.jpg" zu extrahieren. Interessanterweise enthält das Kommentarfeld den Hinweis "Not a part of the VM, he's just cute :3" sowie einen Link zu Pexels. Dies deutet darauf hin, dass das Bild keine sicherheitsrelevante Funktion hat, sondern lediglich zur Dekoration dient.
Ben Chehade's Kommentar: Der Link führt zu dem Originalbild auf Pexels. Dies bestätigt, dass das Bild aus einer externen Quelle stammt und keine spezifischen Informationen über das Zielsystem enthält.
Ben Chehade's Kommentar: Der Quellcode der Seite "/dev/" enthält Kommentare, die Passwort-Hashes für die verschiedenen Teammitglieder enthalten. Die Entwickler haben diese Hashes absichtlich für Testzwecke hinterlassen, was eine äußerst unsichere Vorgehensweise darstellt. Die Kommentare deuten darauf hin, dass die Entwickler sich der Risiken bewusst sind, sie aber dennoch ignorieren.
Ben Chehade's Kommentar: Wir extrahieren die Passwort-Hashes, um sie in einem nächsten Schritt zu knacken.
Ben Chehade's Kommentar: Wir verwenden Crackstation.net, um die Passwort-Hashes zu knacken. Die Ergebnisse zeigen, dass die Hashes für "nick" und "sarah" erfolgreich als "bulldog" bzw. "bulldoglover" geknackt wurden. Dies ist ein kritischer Fund, da wir nun über gültige Anmeldeinformationen verfügen.
Ben Chehade's Kommentar: Mit den geknackten Passwörtern versuchen wir nun, uns bei der Web-Shell anzumelden. Ein erfolgreicher Login würde uns die Möglichkeit geben, Befehle auf dem Server auszuführen und unsere Angriffsfläche zu erweitern.
Ben Chehade's Kommentar: Wir melden uns mit dem Benutzernamen "sarah" und dem Passwort "bulldoglover" bei der Web-Shell an. Der erfolgreiche Login ermöglicht uns den Zugriff auf die Django-Administrationsoberfläche und die Web-Shell selbst.
Ben Chehade's Kommentar: Die Web-Shell schränkt die ausführbaren Befehle auf eine Whitelist ein. Dies erschwert das Ausführen beliebiger Befehle, erfordert aber, dass wir kreative Wege finden, um diese Einschränkungen zu umgehen.
Ben Chehade's Kommentar: Der Versuch, den Befehl "id" auszuführen, wird von der Web-Shell blockiert. Dies bestätigt, dass die Whitelist-Einschränkung aktiv ist.
Ben Chehade's Kommentar: Der Befehl "pwd" gibt das aktuelle Arbeitsverzeichnis "/home/django/bulldog" zurück. Dies gibt uns einen Einblick in die Dateisystemstruktur des Servers.
Ben Chehade's Kommentar: Der Befehl "ls" listet die Dateien im aktuellen Verzeichnis auf. Wir sehen die Django-Projektdateien "bulldog", "db.sqlite3" und "manage.py".
Ben Chehade's Kommentar: Der Befehl "ifconfig" zeigt die Netzwerkkonfiguration des Servers. Wir sehen die IP-Adresse, MAC-Adresse und andere Netzwerkdetails.
Ben Chehade's Kommentar:
Wir verwenden Msfvenom, um einen Reverse-TCP-Payload für Linux x86 zu erstellen.
Die Optionen bedeuten:
-p: Payload (linux/x86/meterpreter/reverse_tcp)
LHOST: Lokale IP-Adresse des Angreifers (192.168.2.137)
LPORT: Lokaler Port des Angreifers (5555)
-f: Format (elf)
>: Speichert die Ausgabe in der Datei "shell.elf"
Dieser Payload wird verwendet, um eine Verbindung vom Zielsystem zurück zum Angreifer herzustellen.
Ben Chehade's Kommentar: Wir versuchen, den Payload "shell.elf" über die Web-Shell auf das Zielsystem zu übertragen. Da die Web-Shell eingeschränkte Befehle zulässt, verwenden wir "echo" und "wget", um den Payload herunterzuladen.
Ben Chehade's Kommentar: Wir starten einen einfachen HTTP-Server auf unserem lokalen System, um den Payload bereitzustellen. Die Fehlermeldung "404 File not found" deutet darauf hin, dass der Payload nicht korrekt bereitgestellt wird.
Ben Chehade's Kommentar: Nachdem wir das Problem mit der Payload-Bereitstellung behoben haben, erhalten wir den Statuscode "200 OK", was bedeutet, dass der Payload erfolgreich heruntergeladen wurde.
Ben Chehade's Kommentar: Wir überprüfen, ob der Payload "shell.elf" erfolgreich auf das Zielsystem übertragen wurde. Der Befehl "ls" zeigt, dass die Datei vorhanden ist.
Ben Chehade's Kommentar: Wir ändern die Ausführungsberechtigungen für den Payload "shell.elf" mit dem Befehl "chmod +x". Der Befehl "ls -la" bestätigt, dass die Berechtigungen erfolgreich geändert wurden.
Ben Chehade's Kommentar: Wir starten Netcat auf unserem lokalen System, um auf die eingehende Verbindung vom Payload zu lauschen.
Ben Chehade's Kommentar: Wir führen den Payload "shell.elf" über die Web-Shell aus. Netcat empfängt eine eingehende Verbindung vom Zielsystem, was bedeutet, dass wir erfolgreich eine Reverse-Shell aufgebaut haben.
Ben Chehade's Kommentar: Wir starten Metasploit, um die Reverse-Shell zu verwalten und weitere Aktionen auf dem Zielsystem durchzuführen.
Ben Chehade's Kommentar:
Wir konfigurieren Metasploit, um die Reverse-Shell zu verarbeiten.
Die Optionen bedeuten:
use multi/handler: Verwendet den Multi-Handler-Exploit
set payload: Setzt den Payload auf linux/x86/meterpreter/reverse_tcp
set lhost: Setzt die lokale IP-Adresse auf eth0
set lport: Setzt den lokalen Port auf 5555
Der Befehl "run" startet den Handler und wartet auf die eingehende Verbindung.
Ben Chehade's Kommentar: Wir führen den Payload erneut aus, um eine Meterpreter-Session zu erhalten. Die Ausgabe zeigt, dass eine Meterpreter-Session erfolgreich aufgebaut wurde. Fantastisch! Der Initial Access war erfolgreich!
Ben Chehade's Kommentar: Wir öffnen eine Shell innerhalb der Meterpreter-Session und suchen nach SUID-Binärdateien, die zur Privilege Escalation ausgenutzt werden könnten.
Ben Chehade's Kommentar: Dieser Proof of Concept (POC) demonstriert, wie die Schwachstelle CVE-2021-4034 (PwnKit) in pkexec ausgenutzt werden kann, um Root-Rechte zu erlangen.
Die pkexec-Schwachstelle ermöglicht es einem unprivilegierten Benutzer, Root-Rechte zu erlangen, indem eine speziell präparierte Umgebungsvariable verwendet wird, um pkexec dazu zu bringen, eine beliebige Bibliothek zu laden.
SESSION: Die ID der laufenden Meterpreter-Session.LHOST: Die IP-Adresse des Angreifers.LPORT: Der Port, auf dem der Angreifer auf die Reverse-Shell lauscht.WRITABLE_DIR: Ein beschreibbares Verzeichnis auf dem Zielsystem (z.B. /tmp).Der Exploit sollte erfolgreich eine neue Meterpreter-Session mit Root-Rechten öffnen.
Die folgenden Code-Blöcke zeigen die Schritte zur Ausnutzung der Schwachstelle und den erfolgreichen Erhalt von Root-Rechten.
Die Ausnutzung dieser Schwachstelle ermöglicht es einem Angreifer, vollständige Kontrolle über das System zu erlangen. Dies kann zu Datenverlust, Systemausfällen und anderen schwerwiegenden Folgen führen.
Installiere die neuesten Sicherheitsupdates, um die pkexec-Schwachstelle zu beheben. Implementiere zusätzliche Sicherheitsmaßnahmen, um die Auswirkungen einer erfolgreichen Ausnutzung zu minimieren.
Ben Chehade's Kommentar: Wir nutzen nun die gefundene SUID-Binärdatei oder eine andere Schwachstelle aus, um Root-Rechte zu erlangen.
Ben Chehade's Kommentar: Wir verwenden den "exploit suggester" in Metasploit, um automatisch Exploits zu finden, die auf dem Zielsystem funktionieren könnten.
Ben Chehade's Kommentar: Wir wählen den "local_exploit_suggester" aus und zeigen die verfügbaren Optionen an.
Ben Chehade's Kommentar: Der "exploit suggester" hat mehrere potenzielle Exploits gefunden, darunter "cve_2021_4034_pwnkit_lpe_pkexec", der als "vulnerable" eingestuft wird.
Ben Chehade's Kommentar: Wir wählen den Exploit "exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec" und konfigurieren ihn mit den entsprechenden Optionen. Nach dem Ausführen des Exploits erhalten wir eine neue Meterpreter-Session.
Ben Chehade's Kommentar: Wir überprüfen, ob wir Root-Rechte haben, indem wir den Befehl "getuid" ausführen. Die Ausgabe "Server username: root" bestätigt, dass wir erfolgreich Root-Rechte erlangt haben. Fantastisch! Die Privilege Escalation war erfolgreich! Wir sind jetzt als `root` angemeldet.
Ben Chehade's Kommentar: Wir öffnen eine Shell und führen den Befehl "id" aus, um unsere Identität zu bestätigen. Die Ausgabe zeigt, dass wir als Root-Benutzer angemeldet sind.
Ben Chehade's Kommentar: Wir lesen die Datei "/root/congrats.txt", um eine Nachricht vom Ersteller der VM zu erhalten.